Makes cped_slot the field that the reader checks before it dereferences anything, and orders the writes to the thread local structure around it so it's written last on construction and cleared first on destruction.

I'm in the process of writing an OTEP specification for the Node.js thread context protocol, so I'm ironing out some wrinkles I'm coming across with observable ordering of writes etc.

Why cped_slot rather than undefined_addr

Our initial recommendation was to check undefined_addr not being zero for this, but it was actually serving two purposes: the value a reader compares against to detect "no context attached", and the liveness flag.

I decided to instead use cped_slot for the liveness, for the following reasons:

• It's the first pointer the reader needs to dereference, so it makes sense for it to act as the gate. cped_slot != 0 says "there is a slot to read", and undefined_addr != 0 says "someone initialized this struct at some point".
• The two already disagree on Node < 22, where cped_slot remains null because that V8 has no CPED but undefined_addr is set to non-zero. (We keep using undefined_addr != 0 as our internal "someone initialized this struct" signal, though.)

The ordering

This really started out as an a-ha moment of "if undefined_addr is used by the reader as a gate, then I must make sure its initialization order is guaranteed", which then led me to "wait, why are we using undefined_addr and not cped_slot for this?".

And to boot, the order for undefined_addr gate was actually wrong, as it was cleared last so it'd still be nonzero in front of other already-cleared fields and the reader can stop the thread while this is happening and observe the inconsistency. This was harmless in practice only because the cleared fields are null and cross-process reads of address 0 fail, so… safety by accident.

Both stores are now volatile behind an atomic_signal_fence and ordered to happen correctly.